home *** CD-ROM | disk | FTP | other *** search
/ Aminet 5 / Aminet 5 - March 1995.iso / Aminet / misc / amag / AM9409_1.lha / VT-Schutz V2.67 / VT.Dokumente / VT.RootBlT < prev    next >
Text File  |  1994-08-24  |  13KB  |  247 lines
  1.  
  2.    VT.RootBlTest     frueher BitMapTest
  3.  
  4.    Taste = R   oder  Mausklick
  5.  
  6.    Stand:10.10.93
  7.  
  8.    Original-WB-Rootblock leicht modifiziert
  9.             Block:     880
  10.  00000000: 00000002 00000000 00000000 00000048 ...............H
  11.  00000010: 00000000 f099533b 00000400 00000372 ......S;.......r
  12.                               ^^^^^^^
  13.  00000020: 00000000 00000000 00000374 00000000 ...........t....
  14.  00000030: 00000000 00000375 00000377 0000041b .......u...w....
  15.  00000040: 00000000 00000000 00000000 00000000 ................
  16.  00000050: 00000000 00000371 00000000 0000045d .......q.......]
  17.  00000060: 00000000 00000000 00000000 00000000 ................
  18.  00000070: 00000475 00000000 00000498 000004ab ...u............
  19.  00000080: 00000000 00000000 00000000 00000000 ................
  20.  00000090: 00000000 00000000 00000000 FFFF0800 ................
  21.                                        ^^^^^^^
  22.  000000a0: 00000000 00000000 00000000 00000000 ................
  23.  000000b0: 00000000 000004ac 00000000 00000000 ................
  24.  000000c0: 00000000 00000000 00000000 00000000 ................
  25.  000000d0: 000004f0 00000000 00000000 00000000 ................
  26.  000000e0: 00000000 00000000 00000501 00000000 ................
  27.  000000f0: 00000504 00000000 00000506 00000000 ................
  28.  00000100: 00000509 00000000 00000000 00000000 ................
  29.  00000110: 00000000 0000050b 00000000 00000000 ................
  30.  00000120: 00000000 0000050d 00000000 0000050f ................
  31.  00000130: 0000054d 00000000 ffffffff 000004a6 ...M............
  32.                               ^^^^^^^  ^^^^^^^
  33.  00000140: 00000000 00000000 00000000 00000000 ................
  34.             ^^^^^^^
  35.  00000150: 00000000 00000000 00000000 00000000 ................
  36.  00000160: 00000000 00000000 00000000 00000000 ................
  37.  00000170: 00000000 00000000 00000000 00000000 ................
  38.  00000180: 00000000 00000000 00000000 00000000 ................
  39.  00000190: 00000000 00000000 00000000 00000000 ................
  40.  000001a0: 00000000 00000f6d 000003e8 000004df .......m........
  41.  000001b0: 0d576f72 6b62656e 6368312e 33440000 .Workbench1.3D..
  42.  000001c0: 00000000 00000000 00000000 00000000 ................
  43.  000001d0: 00000000 00000000 00000f6d 00000492 ...........m....
  44.  000001e0: 000003c9 00000f6d 000003e8 000004df .......m........
  45.  000001f0: 00000000 00000000 00000000 00000001 ................
  46.  
  47. Test1 fuer Disk undFestplatte:
  48.  
  49.    BiTMapZeigerTest:   ($13c s.o.)
  50.    -----------------
  51.       Bitte verwenden Sie diesen Programmteil bei Disk-Validator-Viren
  52.       verseuchten Disketten. (FileTest und BlockKette melden Bitmap
  53.       ungueltig).
  54.       Fall1: Bitmapflag =$138 im Rootblock ist Null
  55.       VT bietet Neuberechnung an. Danach entnehmen Sie bitte diese
  56.       Disk fuer 10 Sekunden (Betriebssytem "vergisst diese Disk"). Danach
  57.       legen Sie die Disk wieder ein, Filetest muesste laufen.
  58.  
  59.       Fall2: SADDAM hat Zeiger auf den Bitmapblock = $13c im Rootblock
  60.       nach $140 verschoben. VT bietet Aenderung an, danach bitte Disk
  61.       entnehmen. siehe oben
  62.  
  63.       Fall3: SADDAM sitzt auch noch im Disk-Validator. VT bietet Rename
  64.       an. Neuer Name: fal.Disk-Valc  (notwendig damit Hash-Wert stimmt)
  65.       Bitte Disk kurz entnehmen. siehe oben
  66.  
  67.       Fall4: der schlimmste Fall, mir wurden 3 solche Disks zugeschickt.
  68.       $13c UND $140 enthalten den Wert 0. Hier braucht VT ihre Hilfe.
  69.       Loesung: suchen Sie bitte mit BitMapTest auch noch den Disk-
  70.          Validator und falls vorhanden Rename. Rename MUSS gemacht wer-
  71.          den, wenn verseuchter Disk-Validator gefunden wurde. Verseuchte
  72.          Disk bitte entnehmen und offen lassen !!!! Jetzt bitte KReset.
  73.          Booten Sie neu von einer Disk mit ORIGINAL-Disk-Validator. Danach
  74.          legen Sie bitte die verseuchte Disk in DF0 oder DF1. Das Be-
  75.          triebssystem erkennt nun den $13c-Fehler und versucht den
  76.          Disk-Validator von der verseuchten Disk zu laden, was aber nicht
  77.          moeglich ist, da Sie den Namen geaendert haben (hoffentlich !!).
  78.          Also wird der saubere Disk-Validator von der Sys-Disk geladen
  79.          (Bei nur 1 Laufwerk erscheint "insert ...." 2 Wechsel notwendig!)
  80.          Das Betriebssystem schreibt nun $138 u. $13c neu (dauert eine Weile,
  81.          warten Sie bitte bis Laufwerks-LED aus ist.). Jetzt starten Sie
  82.          VT neu und decodieren IRAK-Blocks und loeschen fal.Disk-Valc .
  83.          Bis jetzt (10.07.91) habe ich so  JEDE  SADDAM-verseuchte Disk,
  84.          die mir zugeschickt wurde, retten koennen.
  85.  
  86.       Hinweis  28.07.93
  87.          WICHTIG !!!!!  Dieser Hinweis gilt NUR fuer KS1.3, da ab KS2.04
  88.          der Disk-Validator im ROM sitzt.
  89.          Es handelt sich um ein "brutales" Vorgehen, das Sie nur als
  90.          letzte Rettung verwenden sollten.
  91.          Mir wurde eine Disk zugeschickt, die neben dem SADDAM-Disk-Vali-
  92.          dator auch noch jede Menge bad-HeaderKey-Fehler hatte. Der
  93.          Bitmapzeiger war noch in Ordnung !!! und es waren noch keine
  94.          Files codiert.
  95.          Hallo Othmar aus Wien (PTA-Disk). Ohne Adresse kann ich nicht
  96.          antworten, Deshalb versuch ich es auf diesem Weg !!!!!
  97.          Unter KS2.04 konnte das Virus-File ohne Probleme geloescht wer-
  98.          den.
  99.          Aber mit KS1.3 gab es Probleme wegen der anderen Fehler.
  100.          Gefundener und mehrmals wiederholter Weg:
  101.           - Man braucht KS1.3 (und nur dann kann dieser Weg notwendig
  102.                                sein, zusaetzliche Fehler siehe oben)
  103.           - Eine SCHREIBGESCHUETZTE Bootdisk mit sauberen Disk-Validator
  104.           - Eine verseuchte Disk mit zusaetzlichen Fehlerquellen.
  105.          Ablauf:
  106.          Starten Sie VT
  107.          Falls VT SADDAM im Speicher findet, loeschen.
  108.          Dann RootblockTest
  109.             - bei Bedarf Bitmapzeiger richten
  110.             - Disk-Validator umbenennen in fal.DisV
  111.          Dann BlockITest
  112.             - sobald VT SADDAM findet
  113.                  - zeigen
  114.                  - loeschen  (Frage nach Filetest ignorieren)
  115.          Dann BB->File->BB
  116.             - Laufwerk waehlen
  117.             - L waehlen
  118.             - fal.DiskV anklicken
  119.             - Delete
  120.          Falls jetzt groessere Fehler ausser SADDAM auf der Disk sind,
  121.          erscheint ein GURU. (Hat nichts mit VT zu tun, sondern mit
  122.          dem Betriebssystem)
  123.          Falls nur ein LW, Disk entnehmen und von sauberer Disk neu
  124.          booten.
  125.          SADDAM-Disk einlegen
  126.          Requester erscheint und verlangt Bootdisk (wg.Disk-Validator).
  127.          Bootdisk einlegen und wieder entnehmen.
  128.          SADDAM-Disk einlegen und warten bis Licht ausgeht. Original-
  129.          Disk-Validator behebt Fehler.
  130.          VT-Disk einlegen und VT starten.
  131.          SADDAM-Disk einlegen
  132.          mit BB->File->BB  fal.DiskV loeschen. Geht jetzt OHNE GURU.
  133.          Dieser Dieskwechsel entfaellt bei 2 LWen. Legen Sie ihre
  134.          Saubere Bootdisk in DF0 und die SADDAM-Disk in DF1 .
  135.          Hinweis fuer Othmar: Die bad HeaderKey-Fehler werden behoben,
  136.          wenn Sie jetzt alle Files von der ehemaligen SADDAM-Disk im
  137.          Einzelfile-Copymodus (also copy df1: ram: all) ins RAM kopieren
  138.          und dann wieder zurueck (copy ram: df1: all) .
  139.          Nocheinmal !!! Dieser umstaendliche Weg war nur notwendig:
  140.              - bei KS1.3
  141.              - wegen der bad HeaderKey-Fehler
  142.                (die gleiche Disk OHNE bad HeaderKey war auch unter
  143.                 KS1.3 ohne Probleme zu bearbeiten. Also loesche
  144.                 SADDAM-Virus mit FileTest !!!)
  145.  
  146.  
  147.          Erkennt Zombi-Disk, bitte lesen Sie Zombi-Virus-Text
  148.          Erkennt Freedom-Disk (hoffe ich), lesen Sie Freedom-Text
  149.  
  150.          Kann bei Original-Spielen mit "echtem" FremdFormat den Root-
  151.          block ($370=880) natuerlich nicht zeigen.
  152.  
  153.       Hinweis: Nach Commodore ist die BitMap gueltig, wenn im LW -1 =
  154.          $FFFFFFFF steht. Dies stimmt nur zum Teil. Da das Betriebs-
  155.          system gegen 0 testet (auch KS2.04), wird z.B. auch der Wert 1
  156.          vom Betriebssystem als gueltig angesehen.
  157.  
  158.   Test2 NUR fuer Disk:   (ab VT2.50)
  159.   --------------------
  160.         Falls VT im Verlauf dieses Test Veraenderungen vornehmen will,
  161.         brechen Sie bitte UNBEDINGT ab und fertigen Sie zuerst mit z. B.
  162.         turbobackup eine Kopie dieser Disk an !!!! Lassen Sie die Ver-
  163.         aenderungen von VT dann NUR an der Kopie vornehmen !!!!
  164.         Dieser Test wird nur bei Disketten angeboten. Es wird die Block-
  165.         zeigerliste des Rootblocks (s.o. von $18 bis $134 = 72 Eintraege)
  166.         geprueft.
  167.         Es erscheint ein Requester: Blockzeiger-Test
  168.         Mit "Nein" koennen Sie diesen Test ueberspringen und den RootBlT
  169.         beenden.
  170.         Bei DD-Disketten gibt es die Bloecke 0-1759 = max. $000006DF
  171.         Bei HD-Disketten gibt es die Bloecke 0-3519 = max. $00000DBF
  172.  
  173.         Wie Sie oben feststellen koennen, MUSS NICHT jeder Zeiger in der
  174.         Liste belegt sein, sondern kann auch Null sein. Die  Liste sieht
  175.         also bei jeder Disk anders aus (abhaengig vom Hash-Wert der File-
  176.         und/oder SubDir-Namen).
  177.  
  178.         Fall a:
  179.         Nun tauchen in letzter Zeit immer wieder Disks bei mir auf (auch
  180.         kopierte Fish, die unmoegliche Blockzeiger besitzen. Also z. B.
  181.         $FFFF0800 s. o. bei $9c . Ab KS2.04 werden diese Fehler meist
  182.         abgefangen, aber nicht immer. Mit KS1.3 kommt beim dir- oder
  183.         copy-Befehl SICHER  der GURU. Ich habe KEINE Vorstellung, ob
  184.         ein DiskCopy-Prg. oder die Hardware (Disk oder Laufwerk) diese
  185.         Fehler erzeugt. Ich habe es bis jetzt nicht geschafft, selbst so
  186.         eine Disk zu erstellen.
  187.         VT testet nun im 1. Durchgang jeden Blockzeiger in der Liste auf
  188.         Ueberschreitung der max. Block-Nummer. Sollte dies der Fall sein,
  189.         so erscheint ein Requester:   z. B.
  190.                         Blockzeiger falsch
  191.                             $ 00001400
  192.                      Loeschen           Weiter
  193.         Sie koennen nun zuerst auf dem Bildschirm nachschauen, welcher
  194.         Blockzeiger diesen falschen Inhalt hat.
  195.         Wenn Sie Weiter waehlen, wird der Test abgebrochen und RootBlT
  196.         beendet.
  197.         Waehlen Sie Loeschen, so wird der entsprechende Blockzeiger auf
  198.         Null gesetzt, die RootBlockCheckSum neu berechnet und der Root-
  199.         block auf Disk zurueckgeschrieben. So werden im 1. Durchgang
  200.         alle 72 Zeiger durchgetestet.
  201.  
  202.         Fall b:
  203.         Die Blockzeiger der Liste MUESSEN (Kenntnisstand Feb.93) auf
  204.         einen SubDir-Block oder einen FileHeader-Block zeigen. Es war
  205.         nun 1986/87 ein Trick, gleich nach der RootBlockCheckSum bei
  206.         $18 einen Blockzeiger einzusetzen, der NICHT auf obengenannte
  207.         Blocktypen zeigt, sondern auf einen FileDataBlock. Erfolg damals:
  208.         Unter KS1.1/2/3 konnte man das Spiel booten und ohne Probleme
  209.         damit spielen. Wollte man aber mit dem dir-Befehl sich die Disk
  210.         anschauen, so kam sofort ein Task held ... .
  211.         Unter KS2.04 bekommt man jedoch mit dem dir-Befehl eine Ausgabe
  212.         ohne GURU.
  213.         Irgendjemand bringt nun seit Herbst 92 wieder solche Disketten,
  214.         aber mit Viren verseucht, in Umlauf.
  215.         Mit KS2.04 koennen diese Viren (File, Link, Trojan usw.) ohne
  216.         Problem mit vielen AntiVirusPrg.en entfernt werden.
  217.         Anders sieht es aber fuer die Benutzer von KS1.3 aus. Die Dis-
  218.         ketten koennen NICHT getestet werden.
  219.         Entweder ein Prg. unter KS1.3 bricht den Test ab (VT meldet:
  220.         Object not found) oder die Prg.e verabschieden sich mit GURU .
  221.  
  222.         Deshalb fuehrt VT einen 2. Testdurchgang durch und ueberprueft
  223.         die Zeiger, ob sie auf den richtigen Blocktyp zeigen. Falls nein,
  224.         erscheint ein Requester:  z. B.
  225.                      kein Dir/FileHzeiger
  226.                           $ 00000400
  227.                   Loeschen           Weiter
  228.         Waehlen Sie Weiter, so wird der RootBlT beendet.
  229.         Waehlen Sie Loeschen, so wird der entsprechende Zeiger (NICHT der
  230.         Block) geloescht, die RootBlockCheckSum neu berechnet und der
  231.         Rootblock zurueckgeschrieben.
  232.         Wenn Sie DANACH unter KS1.3 die Disk testen, so sollte das Virus-
  233.         teil gefunden werden.
  234.         Aber auch wenn Sie selbst KS2.04 haben, sollten Sie den falschen
  235.         Block loeschen, das Virusteil loeschen und erst DANN die Disk
  236.         weitergeben. Der Bekannte koennte ja noch KS1.3 haben !!!!!
  237.  
  238.      Hinweis 10.10.93:
  239.         Falls Sie versuchen mit KS1.3 eine FastFileSystem-Disk zu testen,
  240.         erhalten Sie beim Rootblock die Meldung "RootBlockProblem", da
  241.         unter KS1.3 das FastFileSystem noch nicht im ROM eingebaut war.
  242.         Der RootBlock ist unter KS2.04 bestimmt ohne Probleme testbar.
  243.  
  244.         Heiner Schneegold
  245.  
  246.  
  247.